home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Languguage OS 2
/
Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO
/
gnu
/
elispman.lha
/
elispman
/
elisp-26
(
.txt
)
< prev
next >
Wrap
GNU Info File
|
1993-06-01
|
49KB
|
877 lines
This is Info file elisp, produced by Makeinfo-1.55 from the input file
elisp.texi.
This is edition 2.0 of the GNU Emacs Lisp Reference Manual, for
Emacs Version 19.
Published by the Free Software Foundation, 675 Massachusetts Avenue,
Cambridge, MA 02139 USA
Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Foundation.
File: elisp, Node: Abbrev Tables, Next: Defining Abbrevs, Prev: Abbrev Mode, Up: Abbrevs
Abbrev Tables
=============
This section describes how to create and manipulate abbrev tables.
- Function: make-abbrev-table
This function creates and returns a new, empty abbrev table--an
obarray containing no symbols. It is a vector filled with `nil's.
- Function: clear-abbrev-table TABLE
This function undefines all the abbrevs in abbrev table TABLE,
leaving it empty. The function returns `nil'.
- Function: define-abbrev-table TABNAME DEFINITIONS
This function defines TABNAME (a symbol) as an abbrev table name,
i.e., as a variable whose value is an abbrev table. It defines
abbrevs in the table according to DEFINITIONS, a list of elements
of the form `(ABBREVNAME EXPANSION HOOK USECOUNT)'. The value is
always `nil'.
- Variable: abbrev-table-name-list
This is a list of symbols whose values are abbrev tables.
`define-abbrev-table' adds the new abbrev table name to this list.
- Function: insert-abbrev-table-description NAME &optional HUMAN
This function inserts before point a description of the abbrev
table named NAME. The argument NAME is a symbol whose value is an
abbrev table. The value is always `nil'.
If HUMAN is non-`nil', a human-oriented description is inserted.
Otherwise the description is a Lisp expression--a call to
`define-abbrev-table' which would define NAME exactly as it is
currently defined.
File: elisp, Node: Defining Abbrevs, Next: Abbrev Files, Prev: Abbrev Tables, Up: Abbrevs
Defining Abbrevs
================
These functions define an abbrev in a specified abbrev table.
`define-abbrev' is the low-level basic function, while `add-abbrev' is
used by commands that ask for information from the user.
- Function: add-abbrev TABLE TYPE ARG
This function adds an abbreviation to abbrev table TABLE. The
argument TYPE is a string describing in English the kind of abbrev
this will be (typically, `"global"' or `"mode-specific"'); this is
used in prompting the user. The argument ARG is the number of
words in the expansion.
The return value is the symbol which internally represents the new
abbrev, or `nil' if the user declines to redefine an existing
abbrev.
- Function: define-abbrev TABLE NAME EXPANSION HOOK
This function defines an abbrev in TABLE named NAME, to expand to
EXPANSION, and call HOOK. The return value is an uninterned
symbol which represents the abbrev inside Emacs; its name is NAME.
The argument NAME should be a string. The argument EXPANSION
should be a string, or `nil', to undefine the abbrev.
The argument HOOK is a function or `nil'. If HOOK is non-`nil',
then it is called with no arguments after the abbrev is replaced
with EXPANSION; point is located at the end of EXPANSION.
The use count of the abbrev is initialized to zero.
- User Option: only-global-abbrevs
If this variable is non-`nil', it means that the user plans to use
global abbrevs only. This tells the commands that define
mode-specific abbrevs to define global ones instead. This
variable does not alter the functioning of the functions in this
section; it is examined by their callers.
File: elisp, Node: Abbrev Files, Next: Abbrev Expansion, Prev: Defining Abbrevs, Up: Abbrevs
Saving Abbrevs in Files
=======================
A file of saved abbrev definitions is actually a file of Lisp code.
The abbrevs are saved in the form of a Lisp program to define the same
abbrev tables with the same contents. Therefore, you can load the file
with `load' (*note How Programs Do Loading::.). However, the function
`quietly-read-abbrev-file' is provided as a more convenient interface.
User-level facilities such as `save-some-buffers' can save abbrevs
in a file automatically, under the control of variables described here.
- User Option: abbrev-file-name
This is the default file name for reading and saving abbrevs.
- Function: quietly-read-abbrev-file FILENAME
This function reads abbrev definitions from a file named FILENAME,
previously written with `write-abbrev-file'. If FILENAME is
`nil', the file specified in `abbrev-file-name' is used.
`save-abbrevs' is set to `t' so that changes will be saved.
This function does not display any messages. It returns `nil'.
- User Option: save-abbrevs
A non-`nil' value for `save-abbrev' means that Emacs should save
abbrevs when files are saved. `abbrev-file-name' specifies the
file to save the abbrevs in.
- Variable: abbrevs-changed
This variable is set non-`nil' by defining or altering any
abbrevs. This serves as a flag for various Emacs commands to
offer to save your abbrevs.
- Command: write-abbrev-file FILENAME
Save all abbrev definitions, in all abbrev tables, in the file
FILENAME, in the form of a Lisp program which when loaded will
define the same abbrevs. This function returns `nil'.
File: elisp, Node: Abbrev Expansion, Next: Standard Abbrev Tables, Prev: Abbrev Files, Up: Abbrevs
Looking Up and Expanding Abbreviations
======================================
Abbrevs are usually expanded by commands for interactive use,
including `self-insert-command'. This section describes the
subroutines used in writing such functions, as well as the variables
they use for communication.
- Function: abbrev-symbol ABBREV &optional TABLE
This function returns the symbol representing the abbrev named
ABBREV. The value returned is `nil' if that abbrev is not
defined. The optional second argument TABLE is the abbrev table
to look it up in. By default, this function tries first the
current buffer's local abbrev table, and second the global abbrev
table.
- User Option: abbrev-all-caps
When this is set non-`nil', an abbrev entered entirely in upper
case is expanded using all upper case. Otherwise, an abbrev
entered entirely in upper case is expanded by capitalizing each
word of the expansion.
- Function: abbrev-expansion ABBREV &optional TABLE
This function returns the string that ABBREV would expand into (as
defined by the abbrev tables used for the current buffer). The
optional argument TABLE specifies the abbrev table to use; if it is
specified, the abbrev is looked up in that table only.
- Variable: abbrev-start-location
This is the buffer position for `expand-abbrev' to use as the start
of the next abbrev to be expanded. (`nil' means use the word
before point instead.) `abbrev-start-location' is set to `nil'
each time `expand-abbrev' is called. This variable is also set by
`abbrev-prefix-mark'.
- Variable: abbrev-start-location-buffer
The value of this variable is the buffer for which
`abbrev-start-location' has been set. Trying to expand an abbrev
in any other buffer clears `abbrev-start-location'. This variable
is set by `abbrev-prefix-mark'.
- Variable: last-abbrev
This is the `abbrev-symbol' of the last abbrev expanded. This
information is left by `expand-abbrev' for the sake of the
`unexpand-abbrev' command.
- Variable: last-abbrev-location
This is the location of the last abbrev expanded. This contains
information left by `expand-abbrev' for the sake of the
`unexpand-abbrev' command.
- Variable: last-abbrev-text
This is the exact expansion text of the last abbrev expanded, as
results from case conversion. Its value is `nil' if the abbrev
has already been unexpanded. This contains information left by
`expand-abbrev' for the sake of the `unexpand-abbrev' command.
- Variable: pre-abbrev-expand-hook
This is a normal hook whose functions are executed, in sequence,
just before any expansion of an abbrev. *Note Hooks::. Since it
is a normal hook, the hook functions receive no arguments.
However, they can find the abbrev to be expanded by looking in the
buffer before point.
The following sample code shows a simple use of
`pre-abbrev-expand-hook'. If the user terminates an abbrev with a
punctuation character, the function issues a prompt. Thus, this hook
allows the user to decide whether the abbrev should be expanded, and to
abort expansion if it is not desired.
(add-hook 'pre-abbrev-expand-hook 'query-if-not-space)
;; This is the function invoked by `pre-abbrev-expand-hook'.
;; If the user terminated the abbrev with a space, the function does
;; nothing (that is, it returns so that the abbrev can expand). If the
;; user entered some other character, this function asks whether
;; expansion should continue.
;; If the user enters the prompt with `y', the function returns
;; `nil' (because of the `not' function), but that is
;; acceptable; the return value has no effect on expansion.
(defun query-if-not-space ()
(if (/= ?\ (preceding-char))
(if (not (y-or-n-p "Do you want to expand this abbrev? "))
(error "Not expanding this abbrev"))))
File: elisp, Node: Standard Abbrev Tables, Prev: Abbrev Expansion, Up: Abbrevs
Standard Abbrev Tables
======================
Here we list the variables that hold the abbrev tables for the
preloaded major modes of Emacs.
- Variable: global-abbrev-table
This is the abbrev table for mode-independent abbrevs. The abbrevs
defined in it apply to all buffers. Each buffer may also have a
local abbrev table, whose abbrev definitions take precedence over
those in the global table.
- Variable: local-abbrev-table
The value of this buffer-local variable is the (mode-specific)
abbreviation table of the current buffer.
- Variable: fundamental-mode-abbrev-table
This is the local abbrev table used in Fundamental mode. It is the
local abbrev table in all buffers in Fundamental mode.
- Variable: text-mode-abbrev-table
This is the local abbrev table used in Text mode.
- Variable: c-mode-abbrev-table
This is the local abbrev table used in C mode.
- Variable: lisp-mode-abbrev-table
This is the local abbrev table used in Lisp mode and Emacs Lisp
mode.
File: elisp, Node: Processes, Next: System Interface, Prev: Abbrevs, Up: Top
Processes
*********
In the terminology of operating systems, a "process" is a space in
which a program can execute. Emacs runs in a process. Emacs Lisp
programs can invoke other programs in processes of their own. These are
called "subprocesses" or "child processes" of the Emacs process, which
is their "parent process".
A subprocess of Emacs may be "synchronous" or "asynchronous",
depending on how it is created. When you create a synchronous
subprocess, the Lisp program waits for the subprocess to terminate
before continuing execution. When you create an asynchronous
subprocess, it can run in parallel with the Lisp program. This kind of
subprocess is represented within Emacs by a Lisp object which is also
called a "process". Lisp programs can use this object to communicate
with the subprocess or to control it. For example, you can send
signals, obtain status information, receive output from the process, or
send input to it.
- Function: processp OBJECT
This function returns `t' if OBJECT is a process, `nil' otherwise.
* Menu:
* Subprocess Creation:: Functions that start subprocesses.
* Synchronous Processes:: Details of using synchronous subprocesses.
* Asynchronous Processes:: Starting up an asynchronous subprocess.
* Deleting Processes:: Eliminating an asynchronous subprocess.
* Process Information:: Accessing run-status and other attributes.
* Input to Processes:: Sending input to an asynchronous subprocess.
* Signals to Processes:: Stopping, continuing or interrupting
an asynchronous subprocess.
* Output from Processes:: Collecting output from an asynchronous subprocess.
* Sentinels:: Sentinels run when process run-status changes.
* Transaction Queues:: Transaction-based communication with subprocesses.
* TCP:: Opening network connections.
File: elisp, Node: Subprocess Creation, Next: Synchronous Processes, Up: Processes
Functions that Create Subprocesses
==================================
There are three functions that create a new subprocess in which to
run a program. One of them, `start-process', creates an asynchronous
process and returns a process object (*note Asynchronous Processes::.).
The other two, `call-process' and `call-process-region', create a
synchronous process and do not return a process object (*note
Synchronous Processes::.).
Synchronous and asynchronous processes are explained in following
sections. Since the three functions are all called in a similar
fashion, their common arguments are described here.
In all cases, the function's PROGRAM argument specifies the program
to be run. An error is signaled if the file is not found or cannot be
executed. The actual file containing the program is found by following
normal system rules: if the file name is absolute, then the program
must be found in the specified file; if the name is relative, then the
directories in `exec-path' are searched sequentially for a suitable
file. The variable `exec-path' is initialized when Emacs is started,
based on the value of the environment variable `PATH'. The standard
file name constructs, `~', `.', and `..', are interpreted as usual in
`exec-path', but environment variable substitutions (`$HOME', etc.) are
not recognized; use `substitute-in-file-name' to perform them (*note
File Name Expansion::.).
Each of the subprocess-creating functions has a BUFFER-OR-NAME
argument which specifies where the standard output from the program will
go. If BUFFER-OR-NAME is `nil', that says to discard the output unless
a filter function handles it. (*Note Filter Functions::, and *Note
Streams::.) Normally, you should avoid having multiple processes send
output to the same buffer because their output would be intermixed
randomly.
All three of the subprocess-creating functions have a `&rest'
argument, ARGS. The ARGS must all be strings, and they are supplied to
PROGRAM as separate command line arguments. Wildcard characters and
other shell constructs are not allowed in these strings, since they are
passed directly to the specified program.
*Please note:* the argument PROGRAM contains only the name of the
program; it may not contain any command-line arguments. Such arguments
must be provided via ARGS.
The subprocess gets its current directory from the value of
`default-directory' (*note File Name Expansion::.).
The subprocess inherits its environment from Emacs; but you can
specify overrides for it with `process-environment'. *Note System
Environment::.
- Variable: exec-directory
The value of this variable is the name of a directory (a string)
that contains programs that come with GNU Emacs, that are intended
for Emacs to invoke. The program `wakeup' is an example of such a
program; the `display-time' command uses it to get a reminder once
per minute.
The default value is the name of a directory whose name ends in
`arch-lib'. We call the directory `emacs/arch-lib', since its
name usually ends that way. We sometimes refer to "the directory
`emacs/arch-lib'," when strictly speaking we ought to say, "the
directory named by the variable `exec-directory'." Most of the
time, there is no difference.
(In earlier Emacs versions, prior to version 19, these files lived
in the directory `emacs/etc' instead of in `emacs/arch-lib'.)
- User Option: exec-path
The value of this variable is a list of directories to search for
programs to run in subprocesses. Each element is either the name
of a directory (i.e., a string), or `nil', which stands for the
default directory (which is the value of `default-directory').
The value of `exec-path' is used by `call-process' and
`start-process' when the PROGRAM argument is not an absolute file
name.
File: elisp, Node: Synchronous Processes, Next: Asynchronous Processes, Prev: Subprocess Creation, Up: Processes
Creating a Synchronous Process
==============================
After a "synchronous process" is created, Emacs waits for the
process to terminate before continuing. Starting Dired is an example of
this: it runs `ls' in a synchronous process, then modifies the output
slightly. Because the process is synchronous, the entire directory
listing arrives in the buffer before Emacs tries to do anything with it.
While Emacs waits for the synchronous subprocess to terminate, the
user can quit by typing `C-g', and the process is killed by sending it
a `SIGKILL' signal. *Note Quitting::.
The synchronous subprocess functions return `nil' in version 18. In
version 19, they will return an indication of how the process
terminated.
- Function: call-process PROGRAM &optional INFILE BUFFER-OR-NAME
DISPLAY &rest ARGS
This function calls PROGRAM in a separate process and waits for it
to finish.
The standard input for the process comes from file INFILE if
INFILE is not `nil' and from `/dev/null' otherwise. The process
output gets inserted in buffer BUFFER-OR-NAME before point, if
that argument names a buffer. If BUFFER-OR-NAME is `t', output is
sent to the current buffer; if BUFFER-OR-NAME is `nil', output is
discarded.
If BUFFER-OR-NAME is the integer 0, `call-process' returns `nil'
immediately and discards any output. In this case, the process is
not truly synchronous, since it can run in parallel with Emacs;
but you can think of it as synchronous in that Emacs is
essentially finished with the subprocess as soon as this function
returns.
If DISPLAY is non-`nil', then `call-process' redisplays the buffer
as output is inserted. Otherwise the function does no redisplay,
and the results become visible on the screen only when Emacs
redisplays that buffer in the normal course of events.
The remaining arguments, ARGS, are strings that are supplied as
the command line arguments for the program.
The value returned by `call-process' (unless you told it not to
wait) indicates the reason for process termination. A number
gives the exit status of the subprocess; 0 means success, and any
other value means failure. If the process terminated with a
signal, `call-process' returns a string describing the signal.
The examples below are both run with the buffer `foo' current.
(call-process "pwd" nil t)
=> nil
---------- Buffer: foo ----------
/usr/user/lewis/manual
---------- Buffer: foo ----------
(call-process "grep" nil "bar" nil "lewis" "/etc/passwd")
=> nil
---------- Buffer: bar ----------
lewis:5LTsHm66CSWKg:398:21:Bil Lewis:/user/lewis:/bin/csh
---------- Buffer: bar ----------
The `dired-readin' function contains a good example of the use of
`call-process':
(call-process
"ls" nil buffer nil dired-listing-switches dirname)
- Function: call-process-region START END PROGRAM &optional DELETE
BUFFER-OR-NAME DISPLAY &rest ARGS
This function sends the text between START to END as standard
input to a process running PROGRAM. It deletes the text sent if
DELETE is non-`nil', which may be useful when the output is going
to be inserted back in the current buffer.
If BUFFER-OR-NAME names a buffer, the output is inserted in that
buffer at point. If BUFFER-OR-NAME is `t', the output is sent to
the current buffer. If BUFFER-OR-NAME is `nil', the output is
discarded. If BUFFER-OR-NAME is the integer 0, the output is
discarded and `call-process' returns `nil' immediately, just as
`call-process' would.
If DISPLAY is non-`nil', then `call-process-region' redisplays the
buffer as output is inserted. Otherwise the function does no
redisplay, and the results become visible on the screen only when
Emacs redisplays that buffer in the normal course of events.
The remaining arguments, ARGS, are strings that are supplied as
the command line arguments for the program.
The return value of `call-process-region' is just like that of
`call-process': `nil' if you told it to return without waiting;
otherwise, a number or string which indicates how the subprocess
terminated.
In the following example, we use `call-process-region' to run the
`cat' utility, with standard input being the first five characters
in buffer `foo' (the word `input'). `cat' copies its standard
input into its standard output. Since the argument BUFFER-OR-NAME
is `t', this output is inserted in the current buffer.
---------- Buffer: foo ----------
input-!-
---------- Buffer: foo ----------
(call-process-region 1 6 "cat" nil t)
=> nil
---------- Buffer: foo ----------
inputinput-!-
---------- Buffer: foo ----------
The `shell-command-on-region' command uses `call-process-region'
like this:
(call-process-region
start end
shell-file-name ; Name of program.
nil ; Do not delete region.
buffer ; Send output to `buffer'.
nil ; No redisplay during output.
"-c" command) ; Arguments for the shell.
File: elisp, Node: Asynchronous Processes, Next: Deleting Processes, Prev: Synchronous Processes, Up: Processes
Creating an Asynchronous Process
================================
After an "asynchronous process" is created, Emacs and the Lisp
program can continue running immediately. The process may thereafter
run in parallel with Emacs, and the two may communicate with each other
using the functions described in following sections. Here we describe
how to create an asynchronous process, with `start-process'.
- Function: start-process NAME BUFFER-OR-NAME PROGRAM &rest ARGS
This function creates a new asynchronous subprocess and starts the
program PROGRAM running in it. It returns a process object that
stands for the new subprocess for Emacs Lisp programs. The
argument NAME specifies the name for the process object; if a
process with this name already exists, then NAME is modified (by
adding `<1>', etc.) to be unique. The buffer BUFFER-OR-NAME is the
buffer to associate with the process.
The remaining arguments, ARGS, are strings that are supplied as
the command line arguments for the program.
In the example below, the first process is started and runs
(rather, sleeps) for 100 seconds. Meanwhile, the second process
is started, given the name `my-process<1>' for the sake of
uniqueness. It inserts the directory listing at the end of the
buffer `foo', before the first process finishes. Then it
finishes, and a message to that effect is inserted in the buffer.
Much later, the first process finishes, and another message is
inserted in the buffer for it.
(start-process "my-process" "foo" "sleep" "100")
=> #<process my-process>
(start-process "my-process" "foo" "ls" "-l" "/user/lewis/bin")
=> #<process my-process<1>>
---------- Buffer: foo ----------
total 2
lrwxrwxrwx 1 lewis 14 Jul 22 10:12 gnuemacs --> /emacs
-rwxrwxrwx 1 lewis 19 Jul 30 21:02 lemon
Process my-process<1> finished
Process my-process finished
---------- Buffer: foo ----------
- Function: start-process-shell-command NAME BUFFER-OR-NAME COMMAND
&rest COMMAND-ARGS
This function is like `start-process' except that it uses a shell
to execute the specified command. The argument COMMAND is a shell
command name, and COMMAND-ARGS are the arguments for the shell
command.
- Variable: process-connection-type
This variable controls the type of device used to communicate with
asynchronous subprocesses. If it is `nil', then pipes are used.
If it is `t', then PTYs are used (or pipes if PTYs are not
supported).
PTYs are usually preferable for processes visible to the user, as
in Shell mode, because they allow job control (`C-c', `C-z', etc.)
to work between the process and its children whereas pipes do not.
For subprocesses used for internal purposes by programs, it is
often better to use a pipe, because they are more efficient. In
addition, the total number of PTYs is limited on many systems and
it is good not to waste them.
The value `process-connection-type' is used when `start-process'
is called, so in order to change it for just one call of
`start-process', temporarily rebind it with `let'.
(let ((process-connection-type nil)) ; Use a pipe.
(start-process ...))
File: elisp, Node: Deleting Processes, Next: Process Information, Prev: Asynchronous Processes, Up: Processes
Deleting Processes
==================
"Deleting a process" disconnects Emacs immediately from the
subprocess, and removes it from the list of active processes. It sends
a signal to the subprocess to make the subprocess terminate, but this is
not guaranteed to happen immediately. (The process object itself
continues to exist as long as other Lisp objects point to it.)
You can delete a process explicitly at any time. Processes are
deleted automatically after they terminate, but not necessarily right
away. If you delete a terminated process explicitly before it is
deleted automatically, no harm results.
- Variable: delete-exited-processes
This variable controls automatic deletion of processes that have
terminated (due to calling `exit' or to a signal). If it is
`nil', then they continue to exist until the user runs
`list-processes'. Otherwise, they are deleted immediately after
they exit.
- Function: delete-process NAME
This function deletes the process associated with NAME. The
argument NAME may be a process, the name of a process, a buffer,
or the name of a buffer. The subprocess is killed with a `SIGHUP'
signal.
(delete-process "*shell*")
=> nil
- Function: process-kill-without-query PROCESS
This function declares that Emacs need not query the user if
PROCESS is still running when Emacs is exited. The process will
be deleted silently. The value is `t'.
(process-kill-without-query (get-process "shell"))
=> t
File: elisp, Node: Process Information, Next: Input to Processes, Prev: Deleting Processes, Up: Processes
Process Information
===================
Several functions return information about processes.
`list-processes' is provided for interactive use.
- Command: list-processes
This command displays a listing of all living processes. (Any
processes listed as `Exited' or `Signaled' are actually eliminated
after the listing is made.) This function returns `nil'.
- Function: process-list
This function returns a list of all processes that have not been
deleted.
(process-list)
=> (#<process display-time> #<process shell>)
- Function: get-process NAME
This function returns the process named NAME, or `nil' if there is
none. An error is signaled if NAME is not a string.
(get-process "shell")
=> #<process shell>
- Function: process-command PROCESS
This function returns the command that was executed to start
PROCESS. This is a list of strings, the first string being the
program executed and the rest of the strings being the arguments
that were given to the program.
(process-command (get-process "shell"))
=> ("/bin/csh" "-i")
- Function: process-exit-status PROCESS
This function returns the exit status of PROCESS or the signal
number that killed it. (Use the result of `process-status' to
determine which of those it is.) If PROCESS has not yet
terminated, the value is 0.
- Function: process-id PROCESS
This function returns the PID of PROCESS. This is an integer
which distinguishes the process PROCESS from all other processes
running on the same computer at the current time. The PID of a
process is chosen by the operating system kernel when the process
is started and remains constant as long as the process exists.
- Function: process-name PROCESS
This function returns the name of PROCESS.
- Function: process-status PROCESS-NAME
This function returns the status of PROCESS-NAME as a symbol. The
argument PROCESS-NAME must be either a process or a string. If it
is a string, it need not name an actual process.
The possible values for an actual subprocess are:
`run'
for a process that is running.
`stop'
for a process that is stopped but continuable.
`exit'
for a process that has exited.
`signal'
for a process that has received a fatal signal.
`open'
for a network connection that is open.
`closed'
for a network connection that is closed. Once a connection
is closed, you cannot reopen it, though you might be able to
open a new connection to the same place.
`nil'
if PROCESS-NAME is not the name of an existing process.
(process-status "shell")
=> run
(process-status "never-existed")
=> nil
x
=> #<process xx<1>>
(process-status x)
=> exit
For a network connection, `process-status' returns one of the
symbols `open' or `closed'. The latter means that the other side
closed the connection, or Emacs did `delete-process'.
In earlier Emacs versions (prior to version 19), the status of a
network connection was `run' if open, and `exit' if closed.
File: elisp, Node: Input to Processes, Next: Signals to Processes, Prev: Process Information, Up: Processes
Sending Input to Processes
==========================
Asynchronous subprocesses receive input when it is sent to them by
Emacs, which is done with the functions in this section. You must
specify the process to send input to, and the input data to send. The
data appears on the "standard input" of the subprocess.
Some operating systems have limited space for buffered input in a
PTY. On these systems, the subprocess will cease to read input
correctly if you send an input line longer than the system can handle.
You cannot avoid the problem by breaking the input into pieces and
sending them separately, for the operating system will still have to put
all the pieces together in the input buffer before it lets the
subprocess read the line. The only solution is to put the input in a
temporary file, and send the process a brief command to read that file.
- Function: process-send-string PROCESS-NAME STRING
This function sends PROCESS-NAME the contents of STRING as
standard input. The argument PROCESS-NAME must be a process or
the name of a process.
The function returns `nil'.
(process-send-string "shell<1>" "ls\n")
=> nil
---------- Buffer: *shell* ----------
...
introduction.texi syntax-tables.texi~
introduction.texi~ text.texi
introduction.txt text.texi~
...
---------- Buffer: *shell* ----------
- Command: process-send-region PROCESS-NAME START END
This function sends the text in the region defined by START and
END as standard input to PROCESS-NAME, which is a process or a
process name.
An error is signaled unless both START and END are integers or
markers that indicate positions in the current buffer. (It is
unimportant which number is larger.)
- Function: process-send-eof &optional PROCESS-NAME
This function makes PROCESS-NAME see an end-of-file in its input.
The EOF comes after any text already sent to it.
If PROCESS-NAME is not supplied, or if it is `nil', then this
function sends the EOF to the current buffer's process. An error
is signaled if the current buffer has no process.
The function returns PROCESS-NAME.
(process-send-eof "shell")
=> "shell"
File: elisp, Node: Signals to Processes, Next: Output from Processes, Prev: Input to Processes, Up: Processes
Sending Signals to Processes
============================
"Sending a signal" to a subprocess is a way of interrupting its
activities. There are several different signals, each with its own
meaning. For example, the signal `SIGINT' means that the user has
typed `C-c', or that some analogous thing has happened.
Each signal has a standard effect on the subprocess. Most signals
kill the subprocess, but some stop or resume execution instead. Most
signals can optionally be handled by programs; if the program handles
the signal, then we can say nothing in general about its effects.
The set of signals and their names is defined by the operating
system; Emacs has facilities for sending only a few of the signals that
are defined. Emacs can send signals only to its own subprocesses.
You can send signals explicitly by calling the functions in this
section. Emacs also sends signals automatically at certain times:
killing a buffer sends a `SIGHUP' signal to all its associated
processes; killing Emacs sends a `SIGHUP' signal to all remaining
processes. (`SIGHUP' is a signal that usually indicates that the user
hung up the phone.)
Each of the signal-sending functions takes two optional arguments:
PROCESS-NAME and CURRENT-GROUP.
The argument PROCESS-NAME must be either a process, the name of one,
or `nil'. If it is `nil', the process defaults to the process
associated with the current buffer. An error is signaled if
PROCESS-NAME does not identify a process.
The argument CURRENT-GROUP is a flag that makes a difference when
you are running a job-control shell as an Emacs subprocess. If it is
non-`nil', then the signal is sent to the current process-group of the
terminal which Emacs uses to communicate with the subprocess. If the
process is a job-control shell, this means the shell's current subjob.
If it is `nil', the signal is sent to the process group of the
immediate subprocess of Emacs. If the subprocess is a job-control
shell, this is the shell itself.
The flag CURRENT-GROUP has no effect when a pipe is used to
communicate with the subprocess, because the operating system does not
support the distinction in the case of pipes. For the same reason,
job-control shells won't work when a pipe is used. See
`process-connection-type' in *Note Asynchronous Processes::.
- Function: interrupt-process &optional PROCESS-NAME CURRENT-GROUP
This function interrupts the process PROCESS-NAME by sending the
signal `SIGINT'. Outside of Emacs, typing the "interrupt
character" (normally `C-c' on some systems, and `DEL' on others)
sends this signal. When the argument CURRENT-GROUP is non-`nil',
you can think of this function as "typing `C-c'" on the terminal
by which Emacs talks to the subprocess.
- Function: kill-process &optional PROCESS-NAME CURRENT-GROUP
This function kills the process PROCESS-NAME by sending the signal
`SIGKILL'. This signal kills the subprocess immediately, and
cannot be handled by the subprocess.
- Function: quit-process &optional PROCESS-NAME CURRENT-GROUP
This function sends the signal `SIGQUIT' to the process
PROCESS-NAME. This signal is the one sent by the "quit character"
(usually `C-b' or `C-\') when you are not inside Emacs.
- Function: stop-process &optional PROCESS-NAME CURRENT-GROUP
This function stops the process PROCESS-NAME by sending the signal
`SIGTSTP'. Use `continue-process' to resume its execution.
On systems with job control, the "stop character" (usually `C-z')
sends this signal (outside of Emacs). When CURRENT-GROUP is
non-`nil', you can think of this function as "typing `C-z'" on the
terminal Emacs uses to communicate with the subprocess.
- Function: continue-process &optional PROCESS-NAME CURRENT-GROUP
This function resumes execution of the process PROCESS by sending
it the signal `SIGCONT'. This presumes that PROCESS-NAME was
stopped previously.
- Function: signal-process PID SIGNAL
This function sends a signal to process PID, which need not be a
child of Emacs. The argument SIGNAL specifies which signal to
send; it should be an integer.
File: elisp, Node: Output from Processes, Next: Sentinels, Prev: Signals to Processes, Up: Processes
Receiving Output from Processes
===============================
There are two ways to receive the output that a subprocess writes to
its standard output stream. The output can be inserted in a buffer,
which is called the associated buffer of the process, or a function
called the "filter function" can be called to act on the output.
* Menu:
* Process Buffers:: If no filter, output is put in a buffer.
* Filter Functions:: Filter functions accept output from the process.
* Accepting Output:: Explicitly permitting subprocess output.
Waiting for subprocess output.
File: elisp, Node: Process Buffers, Next: Filter Functions, Up: Output from Processes
Process Buffers
---------------
A process can (and usually does) have an "associated buffer", which
is an ordinary Emacs buffer that is used for two purposes: storing the
output from the process, and deciding when to kill the process. You
can also use the buffer to identify a process to operate on, since in
normal practice only one process is associated with any given buffer.
Many applications of processes also use the buffer for editing input to
be sent to the process, but this is not built into Emacs Lisp.
Unless the process has a filter function (*note Filter Functions::.),
its output is inserted in the associated buffer. The position to insert
the output is determined by the `process-mark' (*note Process
Information::.), which is then updated to point to the end of the text
just inserted. Usually, but not always, the `process-mark' is at the
end of the buffer. If the process has no buffer and no filter
function, its output is discarded.
- Function: process-buffer PROCESS
This function returns the associated buffer of the process PROCESS.
(process-buffer (get-process "shell"))
=> #<buffer *shell*>
- Function: process-mark PROCESS
This function returns the marker which controls where additional
output from the process will be inserted in the process buffer.
When output is inserted, the marker is updated to point at the end
of the output. This causes successive batches of output to be
inserted consecutively.
If PROCESS does not insert its output into a buffer, then
`process-mark' returns a marker that points nowhere.
Filter functions normally should use this marker in the same
fashion as is done by direct insertion of output in the buffer. A
good example of a filter function that uses `process-mark' is
found at the end of the following section.
When the user is expected to enter input in the process buffer for
transmission to the process, the process marker is useful for
distinguishing the new input from previous output.
- Function: set-process-buffer PROCESS BUFFER
This function sets the buffer associated with PROCESS to BUFFER.
If BUFFER is `nil', the process will not be associated with any
buffer.
- Function: get-buffer-process BUFFER-OR-NAME
This function returns the process associated with BUFFER-OR-NAME.
If there are several processes associated with it, then one is
chosen. (Presently, the one chosen is the one most recently
created.) It is usually a bad idea to have more than one process
associated with the same buffer.
(get-buffer-process "*shell*")
=> #<process shell>
If the process's buffer is killed, the actual child process is
killed with a `SIGHUP' signal (*note Signals to Processes::.).
File: elisp, Node: Filter Functions, Next: Accepting Output, Prev: Process Buffers, Up: Output from Processes
Process Filter Functions
------------------------
A process "filter function" is a function that receives the standard
output from the associated process. If a process has a filter, then
*all* output from that process, that would otherwise have been in a
buffer, is passed to the filter. The process buffer is used for output
from the process only when there is no filter.
A filter function must accept two arguments: the associated process
and a string, which is the output. The function is then free to do
whatever it chooses with the output.
A filter function runs only while Emacs is waiting (e.g., for
terminal input, or for time to elapse, or for process output). This
avoids the timing errors that could result from running filters at
random places in the middle of other Lisp programs. You may explicitly
cause Emacs to wait, so that filter functions will run, by calling
`sit-for', `sleep-for' or `accept-process-output' (*note Accepting
Output::.). Emacs is also waiting when the command loop is reading
input.
Quitting is normally inhibited within a filter function--otherwise,
the effect of typing `C-g' at command level or to quit a user command
would be unpredictable. If you want to permit quitting inside a filter
function, bind `inhibit-quit' to `nil'. *Note Quitting::.
Many filter functions sometimes or always insert the text in the
process's buffer, mimicking the actions of Emacs when there is no
filter. Such filter functions need to use `set-buffer' in order to be
sure to insert in that buffer. To avoid setting the current buffer
semipermanently, these filter functions must use `unwind-protect' to
make sure to restore the previous current buffer. They should also
update the process marker, and in some cases update the value of point.
Here is how to do these things:
(defun ordinary-insertion-filter (proc string)
(let ((old-buffer (current-buffer)))
(unwind-protect
(let (moving)
(set-buffer (process-buffer proc))
(setq moving (= (point) (process-mark proc)))
(save-excursion
;; Insert the text, moving the process-marker.
(goto-char (process-mark proc))
(insert string)
(set-marker (process-mark proc) (point)))
(if moving (goto-char (process-mark proc))))
(set-buffer old-buffer))))
The reason to use an explicit `unwind-protect' rather than letting
`save-excursion' restore the current buffer is so as to preserve the
change in point made by `goto-char'.
To make the filter force the process buffer to be visible whenever
new text arrives, insert the following line just before the
`unwind-protect':
(display-buffer (process-buffer proc))
To force point to move to the end of the new output no matter where
it was previously, eliminate the variable `moving' and call `goto-char'
unconditionally.
All filter functions that do regexp searching or matching should save
and restore the match data. Otherwise, a filter function that runs
during a call to `sit-for' might clobber the match data of the program
that called `sit-for'. *Note Match Data::.
The output to the function may come in chunks of any size. A program
that produces the same output twice in a row may send it as one batch
of 200 characters one time, and five batches of 40 characters the next.
- Function: set-process-filter PROCESS FILTER
This function gives PROCESS the filter function FILTER. If FILTER
is `nil', then the process will have no filter.
- Function: process-filter PROCESS
This function returns the filter function of PROCESS, or `nil' if
it has none.
Here is an example of use of a filter function:
(defun keep-output (process output)
(setq kept (cons output kept)))
=> keep-output
(setq kept nil)
=> nil
(set-process-filter (get-process "shell") 'keep-output)
=> keep-output
(process-send-string "shell" "ls ~/other\n")
=> nil
kept
=> ("lewis@slug[8] % "
"FINAL-W87-SHORT.MSS backup.otl kolstad.mss~
address.txt backup.psf kolstad.psf
backup.bib~ david.mss resume-Dec-86.mss~
backup.err david.psf resume-Dec.psf
backup.mss dland syllabus.mss
"
"#backups.mss# backup.mss~ kolstad.mss
")
Here is another, more realistic example, which demonstrates how to
use the process mark to do insertion in the same fashion as is done when
there is no filter function:
;; Insert input in the buffer specified by `my-shell-buffer'
;; and make sure that buffer is shown in some window.
(defun my-process-filter (proc str)
(let ((cur (selected-window))
(pop-up-windows t))
(pop-to-buffer my-shell-buffer)
(goto-char (point-max))
(insert str)
(set-marker (process-mark proc) (point-max))
(select-window cur)))
File: elisp, Node: Accepting Output, Prev: Filter Functions, Up: Output from Processes
Accepting Output from Processes
-------------------------------
Output from asynchronous subprocesses normally arrives only while
Emacs is waiting for some sort of external event, such as elapsed time
or terminal input. Occasionally it is useful in a Lisp program to
explicitly permit output to arrive at a specific point, or even to wait
until output arrives from a process.
- Function: accept-process-output &optional PROCESS SECONDS MILLISEC
This function allows Emacs to read pending output from processes.
The output is inserted in the associated buffers or given to their
filter functions. If PROCESS is non-`nil' then this function does
not return until some output has been received from PROCESS.
The arguments SECONDS and MILLISEC let you specify timeout
periods. The former specifies a period measured in seconds and the
latter specifies one measured in milliseconds. The two time
periods thus specified are added together, and
`accept-process-output' returns after that much time whether or
not there has been any subprocess output.
Not all operating systems support waiting periods other than
multiples of a second; on those that do not, you get an error if
you specify nonzero MILLISEC.
The function `accept-process-output' returns non-`nil' if it did
get some output, or `nil' if the timeout expired before output
arrived.